Deploying agoric-sdk with    Cloudflare Pages

View logs

I'll let @michaelfig review the HandledPromise logic in the makeGuest* functions, my brain always hurt thinking of the handler plumbing.

• need to test what kind of error state this goes into. Should be a panic, so that an upgrade can unblock guest execution that got stuck trying to E.

I just had a pesky thought about the following:

const payment= E(purse).withdraw(amount);
foo.receive(payment); // note not using `E` here. `foo` is a guest wrapper of a host local exo

at the time receive is called, payment is a basic HandledPromise unknown to the membrane because the promise handler is always called in a future turn (but always same crank). I honestly do now know how to solve this except providing our own E with our own HandledPromise implementation, or somehow enforce that the payment promise argument becomes know by the next turn, but I'm really warry of going down turn counting routes.

I don't understand the problem. You didn't say what purse is, so let's break it down into two cases

• purse is a guest thing, so the E(purse).withdraw(amount) is completely within the guest side. In this case, payment is a guest-created guest promise. Then, on the next line when payment is used as an argument in a host call, it fails for reasons already tested before this PR: The guest cannot pass guest-created guest promises as arguments in host calls.
• purse, like foo, is guest wrapper of a host remotable. In that case it fails on this line because of exactly the use of E prohibited by this PR.

My guest is you mean the first. But either way, AFAICT, it should work. What am I missing?

I asked

What am I missing?

offline @mhofman explained

basically the problem is that even if purse is a guest wrapper, by the time we see payment used as an argument, the purse "pending / presence handler" has not yet been invoked (delayed by a turn always by eventual send / HandledPromise), so we don't know that payment is a handled promise derived from the membrane.

to which I responded

Right. We’d need to register it during the eventual send itself, which requires some kind of handler to run synchronously, which conflicts with our protection against reentrancy.

Just to separate issues, this threatens #9322 , but not #9443 , right? The latter (#9443) can still proceed?

verifies that passing a guest-created promise as argument of a host call is a panic. With that settled, this PR is Ready for re-review